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ABSTRACT 

DTNSRDC  has  established  the  Technical  Office 
Automation  and  Communications  System  (TOFACS)  to 
utilize  modern  office  automation  technologies.  A 
pilot  broadband  network  was  installed  to  study  the 
effects  of  a  high  speed  network  on  the  produc¬ 
tivity  of  TOFACS.  DTNSRDC  installed  the  MITRENET 
Local  Area  Network  (LAN)  with  the  objective  of 
experiencing  the  use  and  management  of  a  LAN  with 
the  intention  of  eventually  installing  a  perma¬ 
nent,  full  scale  LAN  at  DTNSRDC. 

INTRODUCTION 

David  W.  Taylor  Naval  Ship  Research  and  Development  Center  (DTNSRDC)  has 
established  the  Technical  Office  Automation  and  Communications  System  (TOFACS) 
to  utilize  modern  office  automation  technologies.  The  proliferation  of  TOFACS 
has  intensified  the  need  for  data  communications  throughout  the  Center. 
Therefore,  a  means  of  communicating  data  swiftly  and  reliably  was  and  is  now 
needed.  A  pilot  broadband  network  was  installed  to  study  the  effect  of  a  high 
3peed  network  on  the  productivity  of  TOFACS.  DTNSRDC  installed  the  MITRENET 
local  area  network  (LAN)  with  the  objective  of  experiencing  the  use  and  manage 
ment  of  a  LAN  with  the  intention  of  eventually  installing  a  permanent,  full 
scale  LAN  at  DTNSRDC.  This  report  is  organized  into  four  general  sections: 

MITRE  Implementation 

Present  Status  and  Development  of  the  Network 

Conclusions  and  Summary 

Appendices 

BACKGROUND 

MITRENET  is  a  network  product  of  MITRE  CORP.  There  are  four  versions  of 
MITRENET,  three  of  which  were  developed  at  MITRE  in  Bedford,  Massachusetts. 

The  fourth  and  most  advanced  version  was  developed  at  MITRE's  McLean  Virginia 
facility.  All  four  versions  use  a  Network  Interface  Unit  (NIU)  or  more  common 
ly  known  as  a  3IU  (Bus  Interface  Unit)  which  employs  Carrier  Sense  Multiple 
Access  with  Collision  Detection  (CSMA/CD)  network  access  techniques.  The 
McLean  version  differs  significantly  from  the  previous  versions  in  that  it  is 
oasea  on  a  ziZCO  microprocessor  and  is  ao.ie  to  support  me  Department  of 


Defense,  Transmission  Control  Protocol  (TCP)  and  Internet  Protocol  (IP) 
standards.  The  previous  versions  do  not  support  TCP  or  IP  and  have  consider¬ 
ably  less  capability. 

A  major  implementation  effort  of  MITERNET  was  begun  by  M/A  COM  DCC,  under 
contract  to  MITRE  in  1978.  This  eventually  became  known  as  the  INFORBUS  system 
and  is  based  on  the  z80  microprocessor.  In  1981,  Ideas  Inc.  developed  a 
similar  system  for  the  U.S  House  of  Representatives.  The  Defense 
Communications  Agency  decided  to  sponsor,  beginning  in  1980,  a  more  powerful 
MITRENET-based  network  produced  by  the  MITRE  C3  Division  at  McLean,  Virginia. 
The  Zilog  z8000  development  board  was  selected  as  the  basis  for  the  new  BIU 
(Bus  Interface  Unit)  and  was  manufactured  by  Reaction  Instruments,  Inc.  This 
is  the  MITRENET  currently  installed  at  DTNSRDC. 

MITRE  IMPLEMENTATION  OF  THE  NETWORK  SYSTEM 

According  to  the  MITRE  report  "A  Testbed  Local  Area  Network  at  DTNSRDC  - 
Volume  1:  LAN  overview"  (MTR-84W00122-01 ) ,  the  MITRENET  at  DTNSRDC  uses 
broadband  dual  coaxial  cable.  The  interface  units  to  this  LAN  are  z8000  based 
BIUs.  The  MITRENET  follows  the  (Advanced  Research  Project  Agency/Defense  Data 
Network)  protocols,  these  being  TCP,  IP,  File  Transfer  Protocol  (FTP),  and 
TELNET.  Simple  Mail  Transfer  Protocol  (SMTP),  the  Electronic  Mail  Protocol, 
does  not  support  the  LAN  in  this  prototype.  MITRENET  employs  packet  switching 
technologies . 

Terminals  are  connected  to  the  network  via  Terminal  Interface  Units 
(TIUs)  and  the  host  computers  via  Host  Interface  Units  (HIUs).  The  VAX-1 1/780 
serves  as  the  host  in  DTNSRDC 's  LAN.  The  host  contains  a  UMCZ80  board  (the 
Direct  Memory  Access  (DMA)  device)  which  provides  the  interface  to  the  HIU.  A 
host-to-frontend  protocol,  designed  by  MITRE  Corp.,  is  the  Network  Access 
Protocol  (NAP).  This  protocol  makes  possible  the  interfacing  of  the  host  to 
the  BIU. 

In  the  initial  implementation  by  the  MITRE  Corp.,  the  MITRENET  at  DTNSRDC 
consisted  of  two  subnetworks,  Network  Alpha  and  Network  Bravo.  These 
subnetworks  will  be  discussed  later. 

The  Direct  Memorv  Access  Interface  Unit  IDI'J)  is  a  TIU  with  hardware  and 
software  modifications  to  allow  for  high  speed  RS-422  link  to  a  UNI3US  DMA 
device  (UMCZ30)  for  Digital  Equipment  Corporation  PDP-11  or  VAX  computers.  Up 
to  25  terminals  can  access  the  host  computer  through  the  DIU  simultaneously. 


MITRENET  NETWORK  COMPONENTS 

The  network  components  of  the  MITRENET  consist  of  the  cable  plant,  the 
network  hardware  components,  and  network  software. 

Cable  Plant 

The  LAN  used  at  DTNSRDC  is  a  dual  coaxial  cable  network.  The  cable  it¬ 
self  is  a  JT-3412  semi-rigid  aluminum  shielded  coaxial  cable  (0.312  inch  out¬ 
side  diameter) .  The  components  making  up  the  backbone  are  wideband  linear 
amplifiers,  power  supplies,  taps  (which  allow  devices  to  make  network  connec¬ 
tion,  and  splitters  (to  allow  cable  branching).  Aluminum  cable  (0.412  inch 
diameter)  with  sleeving  to  protect  against  weather  and  water  is  used  where 
the  LAN  backbone  is  placed  between  via  underground  conduits  or  breeze-ways. 

The  Network  uses  4-way  multitap  pairs  situated  every  50  feet  along  the 
network's  aluminum  distribution  cable.  Two  BIUs  can  be  accommodated  on  each  of 
the  4-way  multitap  pair.  Network  Alpha  uses  14  multitap  pairs  and  network 
3ravo  uses  8.  A  minimum  of  one  RS-232C  post  can  be  maintained  at  each  work 
location.  The  UNIX  Operating  System  (UNIX  BSD  4.2)  is  used  on  the  Vax  Host. 

Network  Interface  Units 

The  general  interface  to  the  LAN  is  the  BIU.  The  BIU  was  designed  at 
MITRE  Corporation  in  McLean,  Virginia  and  was  manufactured  by  Reaction 
Instruments  as  Model  442C  NICJ. 

MITRE  Corporation  has  made  some  modifications  to  the  basic  model  442C  so 
that  there  are  now  64K  bytes  of  RAM  memory  and  sockets  for  installing  32K 
bytes  of  PROM  (eight  2732A  EPROM  chips). 

The  BIU  is  a  z8002  microprocessor  unit  with  radio  frequency  (RF)  modems 
and  serial  input/output  (SIO)  ports.  The  RF  modems  modulate  a  carrier  signal 
to  transmit  the  digital  information.  The  middle  frequency  of  this  RF  modem  is 
39  MHz  with  4  MHz  bandwidth.  There  are  four  types  of  BIUs. 

The  first  type  of  BIU  is  the  TIU  which  interfaces  with  the  terminals. 

The  TIU  has  a  configuration  of  ten  RS-232C  ports,  with  each  port  capable  of 


to  communicate  with  a  host  or  another  terminal.  The  TIU  contains  terminal 
interface  software  which  enables  a  user  at  a  terminal  to  connect  to  a  specific 
host  in  the  network. 

The  second  type  of  BIU  is  the  DIU,  which  interfaces  with  the  host  via  a 
high-speed  synchronous  link  from  a  host  DMA  interfacing  device  (the  UMCZ80). 

The  DIU  acts  as  a  frontend  in  the  network  architecture  and  contains  software 
to  implement  its  half  of  the  MITRE-de3igned  host-to-frontend  protocol,  NAP. 

■One  side  of  the  DIU  communicates  to  the  TIU  using  TCP/IP  protocols  through  the 
MITRENET  cable  and  on  the  other  side  it  communicates  to  the  UMCZ80  using  NAP 
(Network  Access  Protocol) .  Both  the  TIU  and  the  DIU  contain  an  operating 
system  called  CMOS  (C  Micro  Operating  System),  and  both  implement  the  lower 
protocol  layers  TCP,  IP,  CSMA/CD,  and  HDLC  (High  level  Data-Link  Control). 

The  third  type  of  BIU  is  the  Host  Interface  Unit  (HIU)  which  interfaces 
with  the  host  RS-232C  ports  on  the  DH-1 1  or  DZ  —  11  devices.  Besides  the  CMOS 
operating  system,  TCP/IP,  CSMA/CD  and  HDLC  protocols,  a  Remote  Control  Process 
(RCP)  is  implemented  in  the  HIU.  The  RCP  provides  basic  network  administrative 
functions  such  as  resetting  connections,  enabling  or  disabling  the  HIU  RS-232 
ports,  and  selecting  the  baud  rate  for  the  RS-232  ports.  The  RCP  can  be  used 
by  someone  located  at  a  location  which  is  remote  from  the  HIU  establishing  a 
TCP  session  over  the  LAN  to  the  host  HIU. 

The  fourth  type  of  BIU  is  the  THIU,  which  utilizes  TIU  hardware  and  HIU 
software.  Up  to  ten  auto-dial  modems  can  be  connected  to  the  THIU.  Users  on 
the  network  can  dial  out  to  the  outside  world.  Because  the  THIU  uses  HIU 
software,  it  also  uses  the  CMOS  operating  system.  This  means  that  the  THIU  is 
a  TIU  configured  as  a  DCE  and  not  a  DTE.  The  THIU  could  be  used  to  replace 
the  HIU  through  the  proper  cable,  thereby  preventing  some  software  problems  in 
iial-out.  The  THIU  is  dedicated  to  connecting  host  computers  and/or  modems. 
User  terminals  cannot  be  attached  to  the  THIUs  or  HIUs. 

;JMCZ80  Microprocessor . 

The  UMCZ80  board  is  a  device  which  gives  the  host  computer  the  ability  to 
interface  a  NIU  via  nigh-speed  link.  The  UMCZ30  uses  a  zoO  microprocessor. 

It  is  manufactured  oy  Associated  Computer  Consultants  and  nas  been  modification 
by  MIT°E  'Corporation .  A  UMCZ30  is  installed  in  each  of  MITPENET’s  host's 


UNIBUS  slot.  Most  of  UMCZ50'3  software  (90t)  is  written  in  C  Language. 


Some  of  the  low-level  software  is  written  in  z80  assembly  language.  MITRE 
maintained  the  UMCZ80's  software  by  a  Z80C  cross  compiler  on  a  PDP  11/70 
running  UNIX  Version  6.  MITRE  had  purchased  this  cross  compiler  from 
Interactive  Systems. 

DMA  transfer  between  both  UMCZ80  and  VAX-11/780  memories  is  possible 
since  the  'JMCZ80  supports  DMA  capability. 

The  UMCZ80  contains  u  Kbytes  of  RAM  and  16  Kbytes  of  PROM  (programmable 
Read  Only  Memory).  The  PROMs  are  made  of  four  2732A  EPROM  chips  that  can  be 
inserted  into  sockets  on  the  UMCZ80  board.  Also,  3 2  Kbytes  of  RAM  located  on 
a  memory  extension  board  can  be  connected  to  the  UMCZ80  processor  board  by 
being  plugged  into  the  host's  UNIBUS.  The  UMCZ80  uses  NAP  to  off-load  the 
host,  thereby  allowing  the  host  to  reach  greater  speeds. 

Communications  between  the  UMCZ80  microprocessor  and  z8000  DIU  is  imple¬ 
mented  through  the  use  of  several  interrupt  service  routines.  For  details  of 
the  UMC  hardware  refer  to  Volume  V  of  a  "A  Testbed  Local  Area  Network  at 
DTNSRDC" . 

Network  Software 

A  large  part  of  NIU  software  is  written  in  C  language.  This  software 
provides  the  LAN’s  lower  level  protocols,  the  CMOS  operating  system,  and  the 
host-to-frontend  protocol.  Part  of  the  software  was  written  in  z8002  assembly 
language.  This  software  was  maintained  by  MITRE  Corp.  using  a  Z8000  C  cross 
compiler  package  running  on  a  PDP-1 V70  UNIX  Version  6.  These  protocols  are 
briefly  described  below,  the  details  of  their  implementations  can  be  found  in 
MTR84-W00 1 22-0 1 .  Currently,  there  are  sets  of  software  used  in  MITRENET's 
TIU,  HIU,  and  DIU. 

For  the  software  residing  in  the  host  computer,  the  MITRENET  uses  NAP  as 
a  means  of  communication  between  the  host's  service  layer  protocol  and  the 
BIU's  lower  layer  protocol. 

The  service  software  used  by  the  VAX-11/780  consists  of  library  sub¬ 
routines  which  are  part  of  each  program.  The  job  of  these  subroutines  is  to 
access  the  protocols  implemented  in  the  DIU. 

Transaction  software  is  part  of  the  UNIX  kernel  and  is  arranged  as  soft¬ 
ware  modules  inside  the  Kernel. 

A  server  program  called  "Itelsrv"  provides  users  a  virtual  terminal 


The  original  VAX-11/UNIX  4.1  BSD  Kernel  was  modified  by  MITRE  Corporation 
Several  source  files  such  as  "nipswitch  .c" ,  "nipaes.c"  and  "nipio.c"  with 
their  included  files  were  added  by  MITRE  Corporation  into  the  UNIX  Kernel  to 
implement  the  transaction  layer  of  the  software.  All  of  the  software  is 
written  in  C  except  for  a  file  called  "niputrap.s"  which  was  written  in  VAX-11 
assembly  language. 

User  parameters  and  data  are  moved  from  the  UNIX  user  level  to  the  Kernal 
level  by  using  the  VAX-11/780  Extended  Function  Code  (XFC)  instruction.  XFC 
acts  as  an  interface  between  the  service  and  the  transaction  software. 

MITRE  Corporation  maintained  VAX  Host  software  using  Vax-b  (Unix  C) 
compiler . 

Software  within  the  host  implements  the  high-level  protocols  to  provide 
the  user  with  network  functions  such  as  communication  between  terminals  and 
file  transfer.  All  software  that  resides  in  the  host  is  written  in  the  high 
levei  C  language. 

As  mentioned  earlier,  part  of  NAP  is  contained  in  the  UMCZ80  to  provide 
speed  and  to  off-load  from  the  host. 

NETWORK  PROTOCOLS 

The  MITRENET  software  follows  standard  layered  protocols,  thus  permitting 
a  variety  of  devices  to  be  connected  to  the  network.  The  NAP  protocol  serves 
as  the  host-to-frontend  protocol.  MITRENET's  software  uses  a  set  of  commands 
to  gain  access  to  the  LAN. 

One  type  of  network  protocol  is  CSMA/CD.  This  protocol  prevents  collision 
between  different  transmissions  traveling  through  the  network.  CSMA  allows  a 
BIU  to  decide  weather  the  path  is  clear  before  going  ahead  and  transmitting 
data . 

Another  protocol  in  the  LAN  is  the  IP  protocol.  IP  provides  a  datagram 
service  for  transmitting  data  through  the  LAN. 

The  TCP  protocol  also  is  employed  on  the  MITERNET.  TCP  assures  a  virtual 
circuit  between  two  processes  occurring  in  interconnected  packet-switched 
networks . 

The  RCP  protocol  is  designed  to  operate  in  the  HIU  or  THU  to  provide 
basic  network  administ-ative  functions. 

Users  can  access  different  hosts  by  utilizing  the  TELNET  protocol.  TELNET 
allows  interoperability  for  asynchronous  scroll  mode  terminals. 


Users  operating  from  a  foreign  host  can  access  files  and  transfer  files 
between  hosts  by  using  the  FTP  protocol. 

PRESENT  IMPLEMENTATION  OF  MITRENET  (MAY,  1985) 

TIU's 

Nine  on-line  located  in  buildings:  192  (3),  9  users 

191  ( 3) ,  9  users 
121  ( 1  ) ,  4  users 
17  (3).  25  users 
TOTAL  it  OF  USERS:  (46) 

HIU's 

fiscal  -  vax-b 

dbl  -  Plexus-B  (2  ports),  tower  (1  port) 

VMS  -  Scientific  &  Engineering  VAX 

THIU 

dial-1  -  DCA  355  switch  (10  ports,  4  decicated  high  speed  ports) 

A  burn-in  station  located  in  building  192  room  107,  enables  equipment  to 
be  tested  before  being  installed  on  the  network.  The  idea  behind  the  burn-in 
station  is  to  connect  BIUs  on-line  with  the  the  network  before  replacing  an 
inoperative  BIU  on  the  network  (usually  a  burn-in  period  should  last  anywhere 
from  three  to  five  days  to  insure  a  successful  replacement).  It  is  recommended 
that  the  future  DTNET  (David  Taylor  local  area  Network)  provide  a  burn-in 
station  completely  separate  from  the  production  LAN  because  experience  has 
shown  that  an  improperly  operating  BIU  can  possibly  bring  down  the  entire 
network.  Furthermore,  all  testing,  integration,  and  future  development  can  be 
done  on  a  much  smaller  scaled  model  of  the  DTNET  without  risking  disruption  on 
the  production  LAN.  The  scaled  model  of  the  DTNET,  or  better  known  as  a  Test 
Bench,  will  insure  smoother  integration  of  components  on  the  Network. 

HARDWARE 

Dutside  equipment  located  at  IMS  (Integrated  Microcomputer  Systems,  Inc.), 
a  local  consulting  firm  formerly  tasked  to  support  the  maintenance  of  the 


MITRENET,  includes  2  UMC  z80  memory  boards,  and  2  UMC  z80  controller  boards. 
This  equipment  was  used  to  build  a  "mini  raitrenet"  at  IMS  using  a  VAX  11/750  as 
the  host  computer. 

All  necessary  hardware,  i.e.,  8IU,s  are  available  for  use.  This  includes 
15  TIU's,  *4  HIU's,  6  DIU;s,  and  2  THIU's.  However,  most  of  the  BIUs  are  not 
working  and  extensive  maintenance  is  being  preformed  to  salvage  an  optimum 
number  of  BIUs  in  order  to  support  the  continuous  operation  of  the  LAN.  Most 
of  the  maintenance  of  the  hardware  is  preformed  by  in-house  personnel  and  BIS. 
DTNSRDC  has  recently  acquired  a  Network  Analyzer  to  ^reform  most  of  the 
troubleshooting  in  the  Bill's  particularly  in  tuning  the  RF-Modems.  Maintenance 
and  the  problems  found  associated  with  the  LAN  will  be  discussed  in  more  detail 
later . 

Distribution  cable  for  making  connection  to  the  taps  on  the  network  is 
available  including  RG-6  F-type  connectors. 

SOFTWARE 

New  HIU  EPROM  software  is  being  installed  in  the  HIU's  because  of  a 
problem  found  in  the  RESET  command  which  has  been  modified  by  IMS.  Other 
numerous  existing  problems  were  discovered.  Many  of  the  problems  have  been 
resolved  (Appendix  A),  such  as  those  with  the  TIU,  HIU,  THIU,  Unix  Kernal  and 
Ltelsrv,  etc.  Due  to  the  limitation  of  funds,  some  problems  have  been 
investigated  but  not  resolved  3uch  as  the  unreliability  of  the  TIU-DIU 
connection,  and  difficulties  with  the  TIU-HIU  connection  in  reaching  steady 
state  at  9600  baud  through  the  MITRENET. 

CABLE  PLANT 

Network  Alpha  and  Network  Bravo  have  been  combined  into  one  logical  LAN 
including  buildings  193,  192,  191,  17,  and  121  with  a  cable  extension  going  to 
building  2  and  19.  Euildis.g  121  cable  plant  has  been  repaired,  tested  and 
tuned  oy  ARC  Engineering.  Installed  at  the  headend  in  building  193  was  an 
eight-way  pair  multi-tap  that  was  needed  to  further  develop  and  add-on  future 
network  resources  in  the  controlled  environment  of  building  193. 

Network  Alpha  uses  a  VAX  ’ 1 '780  and  resides  in  building  1?3-  The  headend 
in  the  MITRENET  takes  signals  comming  from  the  inbound  cable  and  amplies  them 
onto  the  outbound  cable.  The  headend  resides  in  building  193  and  consists  of 
a  signal  splitter,  a  power  combiner,  a  power  supply,  two  line  amplifiers,  and 


three  multitaps.  One  of  the  multitaps  sits  between  the  inbound  and  outbound 
cables  and  causes  the  inbound  signal  to  loop  to  the  outbound  cable. 

PRESENT  STATUS  SUMMARY 

The  present  overall  health  of  the  network  is  good,  running  smoothly 
and  uninterrupted  except  for  planned  shutdowns  for  maintenance,  experimentation 
and  development  on  the  network.  There  will  be,  however,  unplanned  down-time 
on  the  network  for  some  or  all  users  occasionally  due  to  a  faulty  TIU  or  HIU. 

In  most  cases  the  inoperative  BIU  need  only  be  reset.  Even  without  the  support 
and  maintenance  from  the  manufacturer  and  with  limited  or  nonexistent  network 
control  management  the  MITRENET  has  proven  to  be  both  useful  and  effective 
providing  utility  for  approximately  40+  users,  reliable  file  transfer  between 
computer  hosts  and  terminal  devices  on  the  network,  and  practical  hands-on 
experience  for  government  personnel  who  are  involved  with  the  network. 

PAST  EXPERIMENTS 

There  have  been  several  past  experiments  performed  on  the  network  to 
demonstrate  some  of  the  capabilities  of  a  broadband  dual  cable  LAN. 

Video  Security 

There  was  a  video  camera  installed  on  the  network  which  successfully 
demonstrated  video  surveillance  on  a  LAN  cable  plant. 

PA  System 

In  October  1984  a  modulator  was  installed  in  basement  of  building  2  with 
a  demodulator  located  in  building  192.  Voice  was  successfully  broadcast  in 
buildings  191,  192  using  the  LAN  cable  plant  technology  with  greater  quality 
than  the  existing  public  address  system. 

DMA,  DUAL-DMA  (Direct  Memory  Access) 

DMA  .. s  the  implementation  of  the  original  network  design.  This  newly 
pioneered  implementation  provides  greater  processing  power  at  the  front-end  of 
host  computers.  It  handles  up  to  13  users  with  only  one  port  connection  into 
a  JMCZiC  wnien  resides  in  the  host.  Dual  DMA  i3  an  enhancement  of  DMA  which 
will  handle  jp  to  26  users.  Neither  DMA  nor  dual  DMA  are  implemented  at  this 
time  because  it  did  not  prove  to  be  reliable  when  in  use.  '’NOTE:  refer  to 


Appendix  A  which  explains  in  detail  the  problems  associated  with  this 
implementation) . 

PRESENT  DEVELOPMENT 
File  Transfer 

The  File  Transfer  capability  has  been  implemented  using  a  TIU  connected 
to  several  ports  on  VAX-B  located  in  building  192  residing  in  the  same  cabinet 
with  DIAL-1  and  DB1  HIU's.  This  implementation  will  enable  file  transfers 
between  all  hosts  on  the  network  at  a  speed  of  4800  baud.  The  file  transfer 
implementation  using  the  TIU  has  been  successfully  performed  by  IMS  at  their 
location  approximately  nine  months  ago  using  the  KERMIT  protocol.  C-KERMIT 
will  reside  in  public  domain  on  host  computers  on  the  network.  An  inherent 
feature  from  the  TIU-HOST  interface  connection  provides  the  capability  of  a 
remote  access  to  the  MITRENET.  Network  managers  can  access  all  resources  on 
the  network  to  check  the  health  and  operation  of  the  network  from  a  remote 
location . 

File  transfers  have  been  demonstrated  successfully  between  Zenith  120 
microcomputers,  the  Zenith  and  the  Plexus,  the  Zenith  and  the  VAX  11/780,  the 
Zenith  and  the  Apple  Lisa,  the  Zenith  and  the  Tower.  All  microcomputers  use 
the  C-Kermit  File  Transfer  Protocol  and  have  transferred  ASCII  files  in  all 
combinations  of  the  above  microcomputers  with  a  very  low  error  rate  on  the 
network.  The  MITRENET  cannot  however  transfer  binary  files  because  it  strips 
the  eighth  bit. 

Expanded  Resources 

It  is  now  possible  to  expand  host  resources  to  the  network  including  the 
NALCON  VAX  11/750,  and  by  adding  more  ports  onto  the  Plexus  and  Tower 
processors  now  existing  on  the  network.  However,  each  host  will  have  its  owm 
HIU  before  new  users  can  be  brought  on  the  seperate  computer  devices.  As  of 
now  the  Plexus  and  Tower  use  the  same  HIU  due  to  expiremental  purposes  it  is 
impractical  to  use  in  its  present  configuration. 

It  is  now  possible  to  connect  the  VAX  computer  'original  fiscal)  in 
tJ.liing  ’2’.  Several  users  were  brought  on  to  the  MITRENET  in  building  121 
that  demonstrates  the  functionally  and  visibly  expands  the  entire  use  of  the 
network.  Because  of  the  limited  number  of  operational  and  reliable  Interface 
Units  it  is  not  recommended  to  bring  on  any  more  users  at  this  time.  The 


MITRENET  does  however  provide  a  means  of  data  communications  for  users  who  do 
not  have  a  data  line  or  any  other  means  of  communicating  with  remote  host 
computers . 

The  DCA  355  Data  Switch  has  been  integrated  into  the  MITRENET  utilizing  a 
THIU  going  into  the  ST  Handler  (TRUNK)  and  connected  to  the  TT  (TTY)  Handler 
by  the  Node  Super  Processing  Module  that  connects  directly  to  the  TTY  ports  to 
all  of  the  resources  on  the  DCA  355  Network.  The  355  uses  a  character  orient¬ 
ed  protocol  to  connect  to  the  hosts.  All  of  the  processing,  flow  control,  and 
handshaking  is  done  in  the  PM  (processing  module)  which  is  a  Z80  based  micro¬ 
processor  board.  With  this  configuration  it  appears  that  a  greater  baud  rate 
can  be  achieved  (9600  baud)  with  a  very  low  error  rate.  However  only  one  port 
was  connected  to  the  355  in  this  way  and  it  is  unknown  if  this  throughput  can 
be  sustained  if  all  ten  ports  were  connected  at  9600  baud  at  one  time. 

Another  interesting  configuration  using  the  THIU-355  is  when  the  baud  rate  is 
lowered  in  the  THIU  to  1200  baud.  The  355  will  multiplex  the  1200  baud  port 
comming  from  the  THIU  to  all  the  different  host  selections  that  are  presently 
configured  to  speed  match  at  1200  baud,  thus  that  one  port  will  contend  like 
any  other  incoming  port  on  the  DCA  355  Network.  In  effect  that  one  1200  baud 
port  from  the  THIU  can  access  many  more  resources  from  one  THIU  as  opposed  to 
one  HI U  dedicated  to  only  one  Host.  The  software  presently  in  the  HIUs  can 
only  access  one  host  at  that  address.  An  advantage  of  this  configuration 
(THIU  set  at  1200  baud)  a  user  CAN  access  any  host  NOT  on  the  MITRENET  but  can 
access  any  ho3t  resource  on  the  355  using  the  MITRENET.  The  disadvantage  is 
the  tradeoff  in  slower  speed  at  1200  baud. 

PC  Server 

Expirements  were  performed  utilizing  the  Network  as  a  PC  Server.  It  is 
possible  to  interconnect  different  personnel  computers  or  workstations  to  the 
MITRENET  to  access  resources  and  transfer  files  between  workstations  at  remote 
locations  with  some  transparency  to  the  users.  The  PC  Server  included  a  dedi¬ 
cated  Zenith  120  set  in  the  ctty  mode  which  enables  a  remote  user  to  inten¬ 
tionally  open  an  HIU  connection  at  the  Servers  address,  and  take  over  control 
of  the  Zenith  120's  terminal.  Now  the  user  can  access  or  share  any  file  on 
that  PC  including  transferring  that  file  between  different  host  computers  that 
support  tne  same  version  of  C-Kermit  on  the  MITRENET  at  a  transfer  rate  of  9600 


Print  Server 

A  print  server  has  been  attempted  on  the  MITRENET,  however  not  totally 
successful.  Some  of  the  problems  and  difficulties  are: 

1)  Limited  hardware  resources 

The  MITRENET  does  not  support  a  Print  Server.  One  way  to  implement  a  Print 
Server  is  to  connect  a  TIU  to  the  TTY  ports  on  all  or  some  host  computers. 

This  is  not  practical  because  "VAX-B"  has  limited  number  of  TTY  ports  available 
and  those  ports  are  needed  to  support  the  population  of  TOFACS  users.  And  the 
MITRENET  has  a  limited  numbe”  of  working  TIUs  that  are  needed  to  support  the 
users  on  the  network. 

2)  Use  of  HIU  as  Frontend 

Another  approach  would  be  to  use  an  HIU  as  a  frontend  to  the  Print  Server. 
However  there  is  no  way  presently  to  control  the  handshaking  in  the  HIU  alone. 
The  flow  control  cannot  be  managed  in  any  way  in  the  HIU. 

3)  Microcomputer  as  Spooler 

Required  hardware  would  be  an  HIU,  TIU,  and  a  microcomputer  with  three 
communication  ports.  A  print  server  was  developed  with  this  configuration;  a 
HIU  connected  to  an  Apple  LISA  to  logon  spooler,  cu  to  ttyO  out  to  a  TIU,  open 
third  connection  to  source  host,  transfer  file  using  C-Kermit  to  Apple  Lisa, 
print  file  to  Diablo  630  letter  quality  printer.  This  process  works  but  is 
too  cumbersome  to  use.  Too  many  connections  would  have  to  be  made  on  the 
mitrenet  and  the  entire  process  is  impractical  to  use.  It  is  easier  to  use 
the  existing  TOFACS  printing  methods. 

The  MITRENET  does  not  support  a  Print  Server  at  this  time,  and  the  above 
mention  way3  are  not  transparent  enough  for  any  practical  use. 

Software 

When  all  resources  are  identified,  new  address  tables  including  dummy 
symbols  with  address,  will  be  burned  into  the  EPROM  chips  and  installed  in  all 
the  TIU's. 

Hardware 

Special  cable  adapters  are  needed  in  order  to  reconfigure  a  TIU  to  an  HIU 
to  further  develop  and  expand  host  resources  and  workstations  on  the  network. 
These  cable  adapters  will  circumvent  the  need  to  hard  wire  the  SIO  boards  ; n 


when  hard-wiring  and  significantly  reduce  the  amount  of  time  by  just  adding  a 
special  cable  adapter  to  a  TIU  to  easily  convert  to  an  HIU.  There  is  a 
shortage  of  HIU's  and  the  cable  adapters  will  easily  rectify  this  problem. 


Ma  intenance 

Most  all  of  the  maintenance  required  on  the  MITRENET  is  performed  on  the 
BIUs.  Up  until  October  1984  Reaction  Instruments  performed  all  corrective 
maintenance  on  the  BIUs.  After  October  1984  Reaction  Instruments  announced 
they  would  no  longer  manufacture,  support,  or  perform  maintenance  on  the  BIUs. 
Only  four  minor  parts  may  be  replace  in  the  operating  area.  These  are  the 
fuse,  the  "POWER"  switch  lamp,  and  the  two  front  panel  LED’s.  The  following 
equipment  (or  equivalent)  is  required  for  maintenance,  test  and  support  of  the 
Model  442c  Bus  Interface  Unit.  This  equipment  is  utilized  for  alignment, 
calibration  and  testing  of  the  modem  and  digital  logic. 

TEST  EQUIPMENT 


Generator  Supply 
Network  Analyzer 
Phase/Magnitude  Display 
Spectrum  Analyzer 
Digital  Frequency  Counter 
Oscilloscope 
5Vdc  Supply 
12Vdc  Supply 

50/75  ohm  matching  impedance  pads 
MOdb  75ohm  Star-coupler 

DTNSRDC  has  recently  rented  a  Network  Analyzer  which  includes  the 
Spectrum  Analyzer,  Generator  Supply,  and  Frequency  counter  to  do  the  testing 
and  alignment  of  the  modems.  The  test  equipment  and  testing  is  done  at  IMS’s 
location  in  Rockville,  Md.  on  their  "mini  MITRENET.  All  maintenance  on  the 
Bl'J’s  is  now  performed  oy  government  personnel  and  IMS.  The  Network  Analyzer 
is  used  for  modem  alignment  procedures,  transmitter  filter  alignment,  receiver 
‘'liter  alignment,  receiver  discriminator  pre-alignment,  and  receiver  loteotor 


k 


Pre-Alignment.  Some  of  the  more  common  problems  encountered  with  the  checking 
of  an  inoperative  Bill  are: 

o  CPU  chips  may  be  bad.  This  would  cause  the  BIU  to  have  no 
response  at  all.  Would  have  to  replace  the  cpu  chip. 

o  The  BIU  "times-out".  It  is  usually  do  to  a  frequency  shift 
in  the  RF  modem  or  not  enough  "POWER"  at  the  transmitter  or 
receiver  end  of  the  modem. 

o  Bad  components  in  the  motherboard.  DTNSRDC  is  not  equipped 
to  troubleshoot  or  replace  parts  on  the  CPU  board. 

o  No  connection  on  any  one  port,  but  other  ports  are  working 
the  problem  is  most  likely  located  in  the  SIO  board. 

o  Any  combination  is  likely  to  occur.  With  no  spare  parts  the 
BIU's  with  the  more  serious  problem  would  be  cannibalized. 

CONCLUSIONS 

Like  many  other  pioneer  local  area  networks,  the  MITRENET  has  experienced 
several  design  problems.  Since  MITRENET  was  originally  designed  as  an  experi¬ 
mental  network  at  the  MITRE  Corp.,  emphasis  seemed  to  have  been  put  on  the 
demonstration  of  an  operational  network  with  with  little  attention  placed  on 
network  management,  software  maintenance,  and  provisions  for  easy  enhancement 
and  assurances  of  reliability.  Nevertheless,  early  MITRENET  design  strategies 
such  as  the  implementation  of  DMA  at  the  host  with  multiplexing  capability  has 
had  significant  impact  in  the  LAN  industry  and  is  considered  a  leading  step  in 
the  success  of  today's  host-to-host  LAN  products. 

In  the  following,  there  are  problems,  and  several  interesting  issues  that 
have  been  unearthed  about  the  MITRENET. 

IMMATURITY  OF  THE  LAN  INDUSTRY 

Utilization  of  LAN  in  data  communications  has  generally  been  oversold  to 
the  public  since  its  emergence.  LAN  has  been  described  as  an  easy  to  use 
communication  media  that  enables  the  interconnection  and  communication  of  het¬ 
erogeneous  computer  devices.  As  of  today,  this  promise  is  still  essentially  a 
promise.  Most  off-the-shelf  LAN  products  are  still  considered  as  in  their 
infancy  stage.  Installed  base  and  user  experience  on  LAN  products  are  very 
limited.  Most  of  the  cases,  LAN  implementors  and  users  have  to  continue] y 


work  closely  with  LAN  manufacturers  to  identify  and  resolve  network  problems 
that  never  seem  to  stop.  As  one  of  the  early  pioneers  in  using  LANs, 

DTNSRDC's  experience  with  network  problems  can  be  said  as  has  been  certainly 
expected.  Although  the  provisions  of  remedial  actions  to  these  problems  has 
been  complicated  by  the  fact  that  MITRENET  is  not  an  off-the-shelf  commercial 
product  and  is  not  actively  supported  and  maintained  by  its  manufacture  Mitre. 
However,  being  a  research  and  development  laboratory,  taking  a  pioneering  step 
of  selecting  a  RAD  oriented  prototype  network  with  state-of-art  technology  is 
one  of  the  best  ways  to  learn  and  understand  the  technical  fundamentals  in¬ 
volved.  This  is  most  valuable  experience  for  future  development  and  planning. 

IN-HOUSE  EXPERIENCE 

Unlike  off-the-shelf  products,  MITRENET  was  developed,  manufactured,  and 
maintained  by  a  non-profit  research  and  development  oriented  organization  and 
was  later  developed  into  several  different  versions.  The  MITRENET  BIUs  used 
at  DTNSRDC  are  basically  implemented  on  several  Original  Equipment  Manufactur¬ 
ers  (OEM)  28000  microprocessor  boards.  Although  MITRE  Corporation  has  made 
some  modifications  and  enhancements  to  this  board,  the  capability  of  the  BIUs 
were  limited  by  the  available  hardware  design  of  the  boards. 

One  of  the  major  problems  that  the  MITRENET  facing  now  is  the  lack  of 
both  hardware  and  software  support  by  the  original  manufacturers.  Because  of 
this,  significant  in-house  managerial  and  technical  support  is  needed  to  man¬ 
age  and  maintain  the  network.  Despite  its  immaturity,  most  network  users  are 
happy  with  the  networking  capability  and  services  the  MITRENET  provides. 

DEVELOPMENTAL  TOOLS 

The  lack  of  adequate  source  codes  was  the  most  important  factor  that 
slowed  down  the  diagnostic,  development,  and  enhancement  efforts.  Most  of  the 
software  that  resides  inside  the  BIUs  and  the  UMCZ80  board  are  written  in  C 
language.  It  was  impossible  to  modify  the  capability  of  the  BIU  without  the 
source  list  of  the  software  in  the  BIU  and/or  the  UMCZ80.  During  the  last 
year,  IMS  has  tried  to  collect  a  complete  set  of  source  codes  and  development¬ 
al  tools  such  as  a  compatible  Z6CG0  C  cross  compiler  from  MITRE  Corporation. 
Since  MITRE  did  not  keep  a  good  collection  of  a  working  version  of  the  source 
code,  an  incomplete  set  of  software  and  compiler  were  received. 


Apart  from  the  source  code  for  the  networking  software,  several  develop¬ 
mental  equipments  were  required  to  perform  the  diagnostic,  maintenance  and 
enhancement  tasks.  These  include  EPROM  eraser,  Z80  C  crosscompiler ,  and  a 
certain  number  of  EPROMS. 

SUMMARY 

The  MITRENET  Testbed  Local  Area  Network  Project  design  and  purpose  has 
provided  government  personnel  with  the  necessary  and  practical  hands-on 
experience  required  to  successfully  prepare  for  a  more  permanent,  complex,  and 
larger  LAN  that  DTNSRDC  expects  to  manage  in  the  future.  Government  personnel 
and  management  now  have  the  experience  to  foresee  and  isolate  problems  involved 
with  local  area  network  technology,  and  have  a  more  realistic  and  cognizant 
expectation  of  what  a  local  area  network  will  provide  for  the  Navy's  R&D 
Laboratories.  LAN  technology  is  relatively  new  in  the  field  of  Data  Communica¬ 
tions,  a  pilot  project,  such  as  the  MITRENET,  was  a  recommended  and  necessary 
project  to  undertake  prior  to  the  much  more  complex  DTNET  LAN. 

A  lot  of  effort  and  invaluable  support  was  performed  by  IMS  who  has  done 
much  of  the  technical  development  of  this  network.  Because  of  the  nature  of 
this  project  the  Miter  Corporation  was  unable  to  support  and  develop  the  net¬ 
work.  After  several  years  of  development  the  network  is  ready  for  some  limit¬ 
ed  production  and  experimental  use,  and  has  met  all  expectations  from  the 
concept's  original  purpose,  except  for  DMA.  Even  though  the  development  of 
the  DMA  has  been  slow,  it  was  originally  the  major  part  of  the  design  and 
implementation  of  the  network  configuration,  and  least  to  say  the  most  diffi¬ 
cult  to  implement.  Unfortunately,  because  of  the  numerous  problems,  and  lack 
of  tools  and  resources  the  DMA  still  has  several  bugs  in  it  which  at  this  time 
proves  unreliable.  It  would  be  desirable  and  advantageous  to  further  pursue 
the  implementation  of  DMA  of  its  capability  and  most  importantly  the  direction 
of  major  venders  implementations  are  using  DMA.  To  implement  DMA  would  re¬ 
quire  more  effort  by  IMS  and  more  monetary  resources  allocated  to  this  project 
on  the  part  of  DTNSRDC.  To  have  the  DMA  capability  would  be  a  precious  asset 
for  DTNSRDC,  for  those  involved  with  the  LAN,  either  directly  or  indirectly, 
in  obtaining  the  experience,  knowledge  and  possession  of  a  clearly  advanced 
technology  of  local  area  network  host-to-frontend  interconnection.  Everything 
is  now  in  place  to  complete  a  successful  and  reliable  DMA  capability  on  the 
DTNSRDC  MITRENET  LAN  Project.  IMS  has  now  has  the  necessary  resources  (source 


codes  and  compiler  programs)  including  a  "mini"  MITRENET  in  their  Lab  to 
direct  all  efforts  in  ironing  out  the  bugs  to  make  it  reliable.  Some  of  the 
advantages  the  DMA  as  compared  to  the  HIU  are: 

o  Automatically  disconnects  a  virtual  terminal  connection  when 
a  user  doesn't  disconnect  properly.  The  HOST-DMA  connection 
disconnects  automatically  after  a  determined  amount  of  idle  time 
(usually  about  15  minutes). 

o  The  DIU  provides  better  flow  control  to  enable  a  faster  data 
rate  of  9600  baud. 

o  The  DIU  has  a  direct  memory  access  into  a  z80  memory  board  which 
multiplexes  up  to  25  connections  on  a  single  cable  into  the  z80. 

o  The  DIU  implementation  solves  the  problem  of  the  limited  number 
of  tty  ports  on  the  DH-11  (10  ports)  that  the  HIU  needs  and  the 
DIU  hardware  can  now  be  utilized  without  further  reconfiguration. 

Other  problems,  even  though  somewhat  less  important,  but  worth  mentioning 
are  the  failure  of  the  host/HIU  interconnection  to  run  at  9600  baud,  and 
"dirty  power"  in  several  areas  of  the  buildings.  The  HOST/HIU  connection  when 
set  to  9600  baud  looses  characters  in  the  process.  The  HIU  is  presently  set  for 
4800  baud  and  it  is  acceptable  to  operate  at  this  speed  with  a  low  error  rate. 
Installing  power  suppressors  with  noise  filters  on  those  TIU's  that  need  to  be 
reset  several  times  a  day  will  in  most  cases  will  rectify  this  problem.  Also, 
another  important  problem  has  been  uncovered  is  that  the  BIUs  are  heat  sensi¬ 
tive.  When  the  modem  gets  too  warm  the  frequency  shifts  therefore  the  trans¬ 
mission  of  the  signal  is  not  recognized  by  some  or  all  of  the  other  BIUs  on 
the  network.  Removing  the  cover  sometimes  helps,  a  small  fan  placed  directly 
over  the  BIU  works  even  better. 

To  reiterate,  the  MITRENET  pilot  project  was  not  intended  for  production 
use.  This  will  be  the  responsibility  of  the  DTNET.  If  the  MITRENET  will  not 
be  incorporated  into  the  DTNET,  and  it  is  very  likely  it  won't,  it  can  be  well 
utilized  in  a  limited  productive  mode  with  minimal  effort  in  management  and 
maintenance  for  accessings  resources  and  transferring  files  at  the  higher  data 
transmission  speeds.  For  all  intents  and  purposes  the  MITRENET  Testbed  Local 
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IMS  NETWORK  SUPPORT 

DTNSRDC  NETWORK  SUPPORT 

When  IMS  started  to  support  the  MITRENET,  numerous  existing  problems  were 
discovered.  Many  of  these  problems  have  been  resolved,  such  as  those  with  the 
TIU,  HIU,  THIU,  Unix  Kernel  and  Ltelsrv,  etc.  Due  to  the  limitation  of  funds, 
some  problems  have  been  investigated  but  not  resolved  such  as  the  unreliabil¬ 
ity  of  the  TIU-DIU  connection,  and  difficulties  with  the  TIU-HIU  connection  in 
reaching  steady  state  at  9600  baud  through  the  MITRENET.  For  the  unesolved 
problems,  IMS  was  able  to  complete  the  preparation  of  the  tools  used  for  de¬ 
bugging  and  testing,  such  as  obtaining  and  fixing  a  Z8000  C  cross  complier 
package  (to  maintain  the  NIU  software),  purchasing  a  Z80  C  cross  complier  pack¬ 
age  (to  maintain  the  UMCZ80  software),  purchasing  an  EPROM  programmer, 
obtaining  the  source  codes  of  the  UMCZ80  and  the  NIU  software  from  MITRE  Corp. 
and  then  retrieving  the  source  codes  of  the  running  version  od  software  in  the 
UMCZ80  EPROMS. 

In  order  to  facilitate  IMS's  ability  to  work  on  DIU  problems,  debug  the 
Unix  Kernel,  and  implement  dual  DMA  capability,  the  following  actions  were 
taken : 

(1)  A  "mini"  MITRENET  was  installed  at  an  IMS  location  with  similiar 
configuration  to  DTNSRDC's  MITRENET,  and 

(2)  Conversion  of  MITRENET's  version  of  UNIX  Kernel  from  9.1  BSD  to  9.2  BSD. 

IMS  was  successful  in  debugging  the  UNIX  Kernel  on  9. 1  BSD  UNIX  and  in 
fully  implementing  dual  DMA  capability  on  the  9.2  BSD  UNIX  Kernel. 

The  MITRENET  problems  which  IMS  investigated  are  discussed  in  detail  in 
the  following  sections. 

THE  TIU  PROBLEMS  AND  SOLUTIONS 

(1)  Problem  1:  When  a  user  tried  to  close  an  existing  connection  but  type  a 
wrong  name,  the  port  on  the  TIU  died.  The  whole  TIU  needed  to  be  reset 
in  order  to  bring  the  one  port  back  up.  This  problem  was  reported  to  the 
MITRENET  project  manager,  Mr.  Pat  Marques.  He  contacted  MITRE  Corp.  and 
they  fixed  the  problem. 
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(2)  Problem  2:  After  using  the  "+"  command  to  add  a  new  symbol  to  the  symbol 
table  amd  then  trying  to  use  the  command  to  delete  it  from  the  symbol 
table,  the  TIU  displayed  a  "Can't  -  use  close/kill"  message.  However, 
when  using  the  "c"  command,  the  whole  TIU  went  into  the  "panic"  situation 
and  entered  monitor  mode.  Then  the  whole  TIU  died.  The  TIU  needed  to  be 
reset  in  order  to  bring  it  back  up.  The  problem  was  submitted  to  MITRE 
Corp.  and  they  solved  it. 

THE  HIU  PROBLEMS  AND  SOLUTIONS 

The  software  of  the  HIU  and  the  THIU  are  the  same.  IMS  performed  tests 
on  the  THIU.  The  problems  are  discussed  under  the  section  covering  THIU 
problems , 

THE  1HIU  PROBLEMS  AND  SOLUTIONS 

IMS  determined  that  the  THIU  could  be  used  to  replace  the  HIU  through  the 
proper  cable,  thereby  preventing  some  software  problems  in  dial-^ut.  "Tie  THIU 
is  dedicated  to  connecting  host  computers  and/or  modems.  User  terminals  can¬ 
not  be  attached  to  the  THIUs  or  HIUs. 

For  the  hardware  configuration,  IMS  performed  tests  and  used  a  blue  box 
for  diagnostic  purposes  and  was  able  to  find  the  proper  configurations.  IMS 
determined  that  the  THIU  can  be  used  as  a  HIU  with  the  following  cable 
configuration : 
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(1)  Problem  1:  The  information  shown  on  the  RCP  eithe  did  not  reflect  the 
real  status  of  the  THIU  or  there  was  some  other  unknown  problem.  This 
situation  was  sent  to  MITRE  and  they  fixed  the  problem. 

(2)  Problem  2:  The  ports  on  the  THIU  must  be  utilized  in  a  sequence  without 
any  ports  disabled  in  between,  otherwise  the  port  enabled  (shown  as 
disabled)  can  be  connected  but  cannot  be  dialed-out.  MITRE  solved  this 
problem . 

(3)  Problem  3:  According  to  the  MITRE  draft  working  paper  WP-82W000586, 
pages  23-31.  the  HIU  is  configured  without  modem  control  signals. 
However,  IMS  discovered  that  the  THIU,  which  has  modem  control  signals, 
can  be  used  to  replace  the  HIU  without  any  problems.  Thus  the  THIU  is 
equivalent  to  the  HIU. 

(4)  Problem  4:  The  THIU  ports  serve  as  the  DCE  (Data  Communication 
Equipment).  IMS  conducted  a  test  and  found  that  the  standard  "NULL 
Modem”  is  able  to  interface  with  this  DCE. 

The  conf iguration  of  this  NULL  modem  is  described  as  follows: 

THIU  Modem 
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THE  DIU  PRC3LEMS 

AND  SOLUTIONS 

IMS  suspected  there  were  some 

bugs  in 

the  DIU  software  in  the  TIU  to  DIU 

connection  mode. 

However,  IMS  was 

unable 

to  do  any  tests  and  debugging  before 

IMS  had  to  prepar 

e  the  tools  and 

software 

available;  thus,  IMS  had  to  prepare 

the  tools  such  as 

Z3C0C  C  cross 

complier  package,  EPROM  programmer,  down  line 

loader  programs, 

and  an  up-to-date 

version 

of  the  DIU  software. 

(1)  Problem  1:  IMS  could  not  make  any  changes  to  the  DIU  software  without 
the  source  code.  At  that  time  the  source  code  of  the  DIU  was  n  t 


available . 

Solution:  The  source  code  was  obtained  from  MITRE  with  the  help  of  Pat 
Marques . 

(2)  Problem  2:  There  was  no  Z8C00  C  cross  compiler. 

Solution:  IMS  obtained  a  copy  of  the  Z8000  C  cross  compiler  package  from 

MITRE  Corp.  which  was  written  for  UNIX  V 7.  IMS  converted  this  package  to 
run  under  UNIX  4.2  BSD. 

(3)  Problem  3:  The  "Link  Editor"  of  the  Z8000  C  cross  complier  provided  by 
MITRE  Corp.  was  not  the  correct  revision.  After  compilation  of  the  DIU 
software,  IMS  used  a  name  list  command  "nm8k"  from  the  Z8000  C  cross 
complier  package  to  obtain  a  symbol  table  of  the  DIU  object  code  which 
said  "newnm".  Then  IMS  also  ran  "nm8k"  to  an  existing  copy  of  the  MITRE 
Corp.  produced  object  code  from  their  link  editor  and  obtained  a  symbol 
table  saying  "oldnm".  IMS  compared  these  two  symbol  tables  and  found  that 
the  text  part  and  data  part  of  the  object  code  had  different  orienta¬ 
tions  . 

Solution:  IMS  discovered  that  these  two  object  codes  were  produced  by 

different  link  editors.  Another  copy  of  the  source  code  of  the  link 
editor  which  was  written  for  UNIX  V6  was  obtained.  IMS  compared  this 
link  editor  to  the  previous  version  and  found  a  missing  line  in  the  new 
version . 

After  fixing  the  above  problem,  the  "newnm"  for  the  produced  object 
code  had  a  similar  symbol  table  compared  to  the  "oldnm". 

(4)  Problem  4:  The  source  codes  provided  by  MITRE  Corp.  were  not  the  same  as 
the  revision  running  on  the  DIU.  Only  the  object  loading  file  provided 
wa3  the  same  as  the  running  revision.  The  object  code  produced  from  the 
exisitng  DIU  software  was  not  identical  to  the  existing  object  code.  IMS 
might  not  have  been  the  up-to-date  version. 

Solution:  In  order  for  IMS  to  debug  any  DIU  related  problem,  IMS  had  to 

find  the  source  cod  of  the  current  running  DIU  software.  Thus  the  fol¬ 
lowing  actions  were  taken: 
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(a)  IMS  read  the  contents  of  the  8  DIU  EPROMS  in  HEX  format. 

(b)  IMS  modified  a  MITRE  Corp.  furnished  "download"  program  to  produce 
HEX  format  output  from  the  MITRE  supplied  DIU  object  code. 

(c)  After  comparing  the  results  of  (1)  and  (2),  IMS  determined  that  the 
DIU  oect  code  provided  by  MITRE  Corp.  was  the  current  running 
version . 

(d)  Afterwards  IMS  checked  the  "nmnew"  and  "nmold"  and  complied  the  DIU 
software  repeatedly  for  many  times  and  re-created  the  source  code  of 
the  DIU  software. 


(5)  Problem  5:  IMS  identified  a  mistake  in  the  Mitre  documentation  which 

gave  an  erroneous  configuration  of  the  UMCZ80-to-DIU  cable.  On  page  16 
of  Volume  IVb,  "Network  Access  Protocol  Implementation  on  a  UMC  Micro¬ 
computer",  pin  19  of  the  50-pin  edge  connector  is  shown  connected  to  pin 
17  instead  of  pin  15  of  the  25-pin  connector. 

THE  UMCZ80  PROBLEMS  AND  SOLUTIONS 

The  UMCZ80  consist  of  a  processor  board  and  a  memory  expansion  board  on 
the  VAX  UNIBUS.  The  UMCZ80  is  user-programmable  under  Z80  assembly  language 
and  was  implemented  by  MITRE  Corp.  as  part  of  the  NAP.  The  UMCZ80  boards  talk 
to  the  VAX  UNIX  Kernel  through  VAX's  UNIBUS  device  driver  and  talk  to  the 
MITRENET  DIU  using  the  NAP  through  the  RS-422  cable. 

IMS  connected  a  UMCZ80  console  to  monitor  the  status  of  the  UMCZ80  and 
detected  the  same  error  message  whenever  a  user  was  connected  from  a  TIU  port 
to  the  VAX  through  the  DIU  and  after  the  DIU  was  reset. 

In  order  to  understand  the  UMCZ80  console  messages,  IMS  needed  the  source 
code  of  the  UMCZ80.  To  be  able  to  do  any  tests  and/or  debugging,  IMS  needed 
Z8C  C  cross  complier  package.  IMS  relayed  this  problem  to  Mr.  Pat  Marques  and 
then  obtained  the  source  code  for  the  UMCZ80. 


(  1 )  Problem 


There  was  no  C  cross  compiler  package.  IMS  required  the 


proper  Z80  C  compiler  package  to  maintain  the  UMCZ80  software.  Since 
there  were  bugs  in  the  NAP,  IMS  needed  tools  for  testing  and  debugging. 
Solution:  IMS  purchased  a  Z8C  C  compiler  package  from  Interactive  Systems 
Inc.,  the  same  company  where  MITRE  Corp.  purchased  their  Z80  C  cross 
compiler  package. 
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(2)  Problem  2:  The  Z 80  C  cross  compiler  package  purchase  from  the  Interactive 
Systems  Co.  had  been  changed  since  MITRE  Corp.  purchased  it  several  years 
ago.  The  mnemonic  code  of  the  Z80  assembler  was  different. 

Solution:  IMS  converted  all  of  the  Z80  assembly  language  code  of  the  old 

assembler  for  the  new  assembler. 

(3)  Problem  3:  Several  files  in  the  UMCZ80  package  were  missing. 

Solution:  IMS  contacted  MITRE  Corp.  and  obtained  two  missing  files, 

<umc.h>  and  "transfer . C" . 

(4)  Problem  4:  The  I/O  library  routines  were  unavailable  from  MITRE  Corp. 

Solution:  IMS  retrieved  these  I/O  library  routines  (in  assembly  source 

code)  from  a  MITRE  Corp.  furnished  UMC280  object  code  file. 

(5)  Problem  5:  After  fixing  the  above  problems,  a  running  object  code  could 
still  not  be  attained.  IMS  dumped  and  compared  the  object  code  of  the 
compiled  version  (new  code)  and  the  MITRE  Corp.  furnished  object  code 
(old  code)  and  found  that  the  old  code  data  section  always  started  at  an 
even  address;  however,  the  new  code  data  section  did'nt  always  start  at 
an  even  address. 

Solution:  IMS  had  to  modify  some  of  the  C  source  code  in  order  to 

eliminate  the  inconsi stency  of  these  two  versions  of  compiler.  After, 
fixing  this,  IMS  retrieved  the  UMCZ80  source  code  which  could  produce  a 
running  version  of  the  UMCZ80  EPROMs. 

(6)  Problem  6:  The  source  codes  of  UMCZ80  supplied  by  MITRE  Corp.  were  not 

the  running  revision  of  the  EPROMs  inside  the  UMCZ80  processor  board. 
Solution:  IMS  dumped  the  old  and  new  object  codes  and  detected  that  the 

"transfer. C"  was  not  the  running  version.  IMS  modified  "transfer. C"  and 
then  retrieved  the  source  code  of  the  running  version. 

(7)  Problem  7:  After  a  connection  of  the  TIU  to  the  DIU  was  made,  the  b'MCZ80 
debugging  console  printed  a  "/TRcnrO"  message  each  time  a  user  depressed 

a  key  on  the  TIU  terminal. 

Solution:  IMS  compiled  a  version  of  the  UMCZ80  code  with  a  debugging 

message  and  then  ran  a  set  of  EPROMS.  The  debugging  message  showed  this 
error  message  should  not  be  displayed  under  normal  conditions,  thus  IMS 


VAX-1 1/UNIX  KERNEL  AND  "LTELSRV"  SERVER  PROBLEMS  AND  SOLUTIONS 

The  VAX-1 1/UNIX  Kernel  of  MITRENET,  which  contains  libraries  and  files, 
follows  the  NAP  on  the  VAX-11  side.  IMS  found  several  problems  with  the  UNIX 
Kenel . 

At  first,  "vi"  could  not  work  through  MITRENET.  The  open  connection  from 
the  TIU  to  the  DIU  had  a  lot  of  problems  and  was  not  reliable.  Initially,  IMS 
did  not  have  any  source  codes.  IMS  had  to  obtain  the  source  codes  of  the  UNIX 
Kernel  and  Ltelsrv  server  and  then  IMS  was  able  to  isolate  and  fix  many 
problems . 

These  problems  were  system  problems  because  the  protocols  invovled  in  the 
TIU-DIU  connection  included  NAP  and  TCP/IP.  In  order  to  work  on  these 
problems,  IMS  had  to  obtain  tools  to  do  the  tests,  such  as  an  EPROM  programmer 
Z8000  C  cross  compiler  package,  Z80  C  cross  compiler  package,  TIU,  DIU,  UMCZ80 
software,  UNIX  Kernel  and  Ltelsrv  source  code.  Also,  IMS  had  to  set  up  a 
"mini"  MITRENET  at  IMS  to  do  the  tests  and  debugging.  Unfortunately,  due  to 
the  limitation  of  funds,  IMS  completed  the  preliminary  tests  but  did  not  have 
a  chance  to  resolve  these  problems. 

(1)  Problem  1:  The  "vi"  and  "more"  commands  did  not  work  correctly  on  the 
DT80  terminal.  When  a  user  tyuped  "vi  file"  or  "more  file",  it  lost 
characters.  When  IMS  used  a  modified  dt80  termcap  instead  of  vtlOO 
termcap,  the  "vi"  and  "more"  problem  disappeared.  IMS  found  that  the 
padding  characters  in  the  termcap  had  caused  the  problem. 

Solution:  IMS  did  not  have  the  source  code  of  the  UNIX  Kernel  and  the 

"ltelsrv"  yet,  thus  IMS  notified  Mr.  Walter  Lazear  of  this  situation, 
whereupon  MITRE  Corp.  modified  the  UNIX  Kernel  and  fixed  the  problem. 

(2)  Problem  2:  When  an  open  connection  from  the  TIU  to  DIU  existed, 
sometimes  only  a  "connection  open"  message  appeared  but  one  could  not 
login  to  vax-b. 

"Ltelsrv"  kept  printing  the  error  message  "Open  failure."  on  the 
VAX-11  console  until  the  "ltelsrv"  was  killed. 

IMS  performed  tests  and  identified  severl  different  cases: 

o  After  a  VAX  reboot ,  the  first  open  connection  from  the  TIU  to  the 
DIU  was  okay,  but  after  closing  the  open  connection  and  trying  to 
open  connection  again,  only  a  "connection  open"  message  from  the  VAX 


appeared  and  one  could  then  login  to  the  VAX  and  execute  UNIX 
commands.  However,  nothing  was  shown  on  the  screen, 
o  If  any  person  had  used  the  "ptyA'  through  "telnet"  the  ptyA  would 
become  free  after  usage. 

o  If  several  people  have  occupied  pty[A-D]  only  the  "connection  open" 
message  was  shown  but  one  could  not  login  to  the  VAX. 

IMS  found  that  cases  (1)  and  (2)  were  due  to  the  same  problem  which 
meant  thst  if  a  "pty"  had  been  used  by  network  access  then  it  could  not 
be  used  anymore.  Meanwhile  the  "ltelsrv"  kept  printing  "Open  failure." 
to  the  VAX  console  until  it  was  killed.  IMS  learned  that  "ltelsrv"  forks 
two  processes  to  handle  a  virtual  circuit  for  a  connection  between  the 
TIU  and  the  VAX.  One  process  was  doing  the  "transmitting"  to  Net  and  the 
other  process  was  "receiving"  the  inout  from  the  Net.  The  problem  must 
have  happened  on  the  "transmitter"  of  the  "ltelsvr"  process. 

IMS  identified  that  case  (3)  resulted  in  the  improper  mode  of 
pt y [ E  — P ]  mode  was  664. 

With  the  assistance  of  DTNSRDC  personnel,  IMS  logged  login  and  error 
messages  into  a  file  for  several  days  for  purposes  of  examination  and 
diagnosis.  The  file  in  which  two  kinds  of  errors  messages,  "open 
failure"  and  "FLUSHED",  were  logged  grew  very  rapidly. 

Solution:  After  an  extensive  review  of  the  source  code  of  "ltelsvr"  (the 
"ltelsvr. c"  program),  the  source  of  the  "FLUSHED"  error  messages  was 
identified  by  IMS  as  the  "tcptxmt"  procedure  in  "ltelsvr. c". 

It  was  found  that  in  the  procedure,  a  global  variable  called  "errno" 
was  not  reset  after  an  error  condition  had  been  cleared.  IMS  modified 
the  code  so  that  variable  "errno"  would  be  reset  properly. 

After  the  above  modification  and  the  lifting  of  write  protection  of 
all  available  pseudo  ttys  for  every  user,  ail  pseudo  ttys  could  be  used 
by  MITRENET. 

(3)  Problem  3:  In  the  middle  of  a  TIU-DIU  session,  when  a  user  typed  "*C" 
(Ctrl  C),  nothing  was  sent  from  the  VAX.  However,  the  VAX  still 
recognized  the  user’s  typing  and  executed  the  command.  After  having  made 
the  modification  in  Problem  2  above,  and  having  lifted  write  protection 
of  all  available  pseudo  ttys  for  every  user,  typing  the  character 
"ctrl-C"  would  not  make  the  TIU  hang  up  any  more. 
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Problem  4:  After  Problems  1-3  had  been  resolved,  another  problem  was 
revealed : 

After  opening  and  closing  a  TIU-DIU  connection  several  times,  a  user 
trying  to  make  a  connection  would  get  a  "connection  open"  message  but 
would  not  get  the  login  prompt.  When  leaving  this  connection  open  and 
trying  to  open  another  connection,  a  "closed :refused"  message  appeared. 
The  symptoms  of  this  problem  look  similar  to  those  of  Problem  3. 

IMS  use  the  debugger  program,  "adb",  to  monitor  operation  of  the 
UNIX  Kernel  and  found  that  the  "stream"  and  "orequest"  tables  were  two 
common  source  pools  for  system  calls  and  that  MITRENET  software  uses 
these  tables.  IMS  conducted  a  test  to  open/close  connection  and  monitor 
the  operation  of  these  two  buffers  and  determined  that  if  either  the 
"stream"  or  the  "orequest"  table  was  full,  the  MITRENET  died. 

After  extensive  studying  and  tracing  of  several  source  programs 
including  "nipacs.c",  "nipio.c",  "slp.c",  etc.,  IMS  conjectured  that  the 
source  of  the  "orequest"  table  was  not  properly  released  after  a  MITRENET 
TIU-DIU  connection  was  closed. 

IMS  traced  the  operation  of  "tcp_close( )"  of  ltelsrv"  and  "nipclsO" 
of  the  UNIX  Kernel  and  identified  that  the  "orequest"  table  was  not 
properly  released  due  to  bugs  on  both  programs. 

IMS  identified  a  problem  on"/usr/include/local_net/orequest .h" .  The 
rpid"  variable  was  declared  a  character  ("char")  instead  of  an  integer 
"short".  "Char"  is  8  bits  long  while  "short"  is  16  bits  long.  When  the 
process  id  grew  larger  than  127,  it  became  a  negative  number.  The  final 
effect  was  that  when  the  "nipclsO"  procedure  tried  to  open  or  close  a 
stream,  it  would  never  find  the  proper  entry  by  comparing  "ltelsrv's" 
"pid"  with  the  "pid"  in  the  "orequest"  table,  thus  it  could  not  properly 
release  the  "orequest"  table. 

Another  bug  in  "ltelsrv"  also  contributed  to  this  problem.  The 
original  "ltelsrv"  did  not  properly  handle  the  synchronization  of  the 
"transmitter"  and  "receiver"  processes.  The  "transmitter"  is  a  child 
process  of  the  "receiver".  The  "id"  stored  in  the  "orequest"  table  was 
for  the  "receiver"  process  instead  of  for  the  "transmitter"  process. 

When  a  "close"  command  was  issued  from  the  "transmitter",  the  "receiver" 


process  was  terminated  first,  thus,  it  would  not  try  to  release  the 
"orequest"  buffer.  Then  when  the  "transmitter"  was  terminating  and  it 
tried  to  release  the  "orequest"  table  but  could  not  match  the"id"  in  the 
"orequest"  table,  it  left  the  "orequest  table  unreleased. 

Solutions : 

(a)  IMS  modified  the  "orequest. h"  program 

(b)  IMS  synchronized  the  "transmitter"  and  "receiver"  processes. 

To  test  the  proposed  modification  on  the  MITRENET  software, 
modification  of  the  system  kernel  to  facilitate  frequent  shutdowns  and 
reboots  of  the  machine  was  necessary. 

IMS  built  a  small-scale  MITRENET  at  an  IMS  location  with  VAX 
software  configuration  similar  to  the  VAX  computer  at  DTNSRDC. 

(5)  Problem  5:  After  Problem  4  had  been  resolved,  another  problem  was 
revealed:  In  the  middle  of  a  TIU-DIU  session,  suddenly  everything 
stopped.  Nothing  was  received  from  the  VAX  and  everything  typed  was  not 
recognized  by  the  VAX.  When  this  happened,  other  connections  on  the  DIU 
also  died.  If  a  user  tried  to  open  a  connection  from  the  DIU  and  attach 
to  it  at  that  time,  he  could  not  talk  to  the  VAX.  If  a  user  tried  to 
open  one  or  more  connection,  he  would  get  a  "closed  .’refused”  message. 

Dual  DMA  Capability 

The  purpose  of  this  subtask  was  to  implement  the  device  drive  of  the 
UMCZ80  and/or  VAX/UNIX  Kernel  so  that  multiple  UMCZ80s  could  be  supported 
under  the  VAX/UNIX. 

To  implement  the  dual  DMA  capability  required  frequent  shutdowns  of  the 
system  in  order  to  test  and  debug  the  UNIX  Kernel.  DTNRDC  did  not  provide  a 
dedicated  VAX  system  to  support  this  dual  DMA  capability  development. 

Ims  built  a  "mini"  MITRENET  at  IMS  using  the  VAX  11/780  to  enable  IMS  to 
more  easily  perform  the  necessary  tasks.  Furthermore,  IMS's  VAX  wa  running 
UNIX  4.2  BSD;  therefore  IMS  first  had  to  convert  the  UNIX  Kernel  of  the 
MITRENET  software  from  4.1  BSD  UNIX  to  4.2  BSD  UNIX.  After  the  above  steps 
were  taken,  IMS  was  able  to  start  the  implementation.  IMS  has  sucessfully 
implemented  and  tested  the  4.2  BSD  UNIX  Kerne1  to  support  Dual  DMA  capability. 
During  implementation ,  all  the  library  routines  and  also  "ltelsrv",  nipio.C", 
and  "nipacs.C"  and  their  included  files  were  modified. 
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PDP-1 1/UNIX  HARDWARE/KERNEL 

The  MITRENET  used  on  the  PDP-11/70  consists  of  a  DIU,  a  UMCZ80  and  a 
PWB/UNIX  kernel.  The  conf iguration  of  the  PDP-11/70  consists  of  DIU,  a 
UMCZ80  and  a  PWB/UNIX  kernel.  The  configuration  of  the  PDP-11/70  consists  pf 
a  CPU,  memory,  one  console,  one  upper  case  DEC  line  printer,  one  UMCZ80,  one 
TU16  tape  driver  with  controller,  one  TM10  tape  driver  with  controller,  one 
UNIBUS  expansion  cabinet,  and  two  DL11  serial  I/O  lines.  The  UMCZ80  processor 
board  and  memory  board  were  installed  in  the  UNIBUS  expansion  cabinet. 

The  PDP-11/70  occasionally  has  hardware  problems.  Besides  running 
PWB/UNIX  on  the  PDP-11/70,  other  people  also  run  RSX-11  OS  on  it. 

According  to  the  maintenance  agreement  between  DTNSRDC  with  TYMSHARE  Co., 
IMS  has  not  been  allowed  to  touch  the  hardware,  therefore,  IMS  had  to  work 
with  "TYMSHARE"  Co.  people  in  order  to  identify  and/or  resolve 
hardware/software  problems. 

Beacause  other  people  also  use  the  PDP-11/70,  it  is  hard  to  know  whether 
the  problems  already  existed  or  were  new  problems. 

(1)  Problem  1:  PDP-11/70  could  not  boot  under  both  RSX-11  and  PWB/UNIX.  The 

people  from  TYMSHARE  ran  a  diagonistic  and  found  that  two  pins  on  the 
backplane  of  the  PDP-11/70  CPU  cabinet  were  bent  and  shorted.  After 
fixing  this  problem  and  replacing  some  faulted  parts,  RSX-11  was  able  to 
boot,  however,  PWD/UNIX  was  not  able  to  boot. 

Solution:  IMS  checked  the  PDP-11/70  console  message  and  identified  that 
the  UMCZ80  processor  board  was  bad.  After  replacing  the  UMCZ80  board, 
the  PDP-11/70  PWB/UNIX  could  boot  successfully. 

(2)  Problem  2:  Depressing  th  reset  bottom  on  the  DIU  of  the  PDP-11/70  did 

not  cause  the  "NIP:  BIU  reset"  message  to  appear  on  the  PDP-11/70  console. 
Analysis:  IMS  connected  both  a  UMCZ80  debugging  console  and  a  DIU 

debugging  console  and  found  that  when  depressing  the  DIU  reset  button, 

the  UMCZ80  debugging  console  printed  "/HOlock/HOlock/HOlock/h'Olock/HOlock/ 
HOlock/HOlock . . . "  until  halting  the  CPU. 

IMS  did  not  have  the  source  codes  of  the  UMCZ80  and  DIU  yet,  thus 
IMS  discussed  this  problem  with  Mr.  Walter  Lazear  of  MITRE  Corp.  IMS  had 
not  made  any  changes  on  the  PWB/UNIX  Kernel  yet.  Mr.  Walter  Lazear 
recalled  that  the  same  situation  had  happened  several  years  ago, 
explaining  the  problem  was  due  to  a  UNIBUS  repeater  made  by  ACC  which 
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■  i 3  not  allow  DMA  functions  on  the  UNIBUS  expansion  box.  IMS  reported 
this  problem  to  Mr.  Pat  Marques  and  requested  that  he  call  the  TYMSHARE 
people  to  check  out  and/or  remove  the  UNIBUS  repeater. 

Problem  f:  The  running  version  of  the  kernel  could  not  be  rebuilt  from 
tre  existing  source  codes.  This  problem  has  not  been  resolved  due  to 
it  r.er  priority  subtasks. 

FT e 1 1 c t  q ;  The  UMCZ60  could  not  be  configured  by  the  "config"  command 
under  PDP-!’/73  PWB/UNIX.  It  had  to  be  manually  added  to  the 
conf iguration  table  "l.s".  This  problem  has  not  been  resolved  due  to 
priority  sub tasks. 

Problem  5:  The  tape  drivers  in  the  PDP-11/7C  were  not  working.  IMS  had 
made  a  new  version  of  the  kernel  and  wantedto  make  backups  before  doing 
the  test;  however,  the  tape  driver  did  notwork. 

IMS  reported  this  problem  to  Mr  Marques. 
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RECCOMENDATIONS  FOR  ENHANCEMENTS  AND  UTILIZATION  OF  MITRENET 

Ever  since  the  introduction  of  the  MITRENET  products,  MITRENET 
implementation  method  have  taken  a  leading  role  in  LAN  engineering  and 
development.  To  state  these  facts,  MITRENET  was  the  first  LAN  that  utilizes 
TCP/IP  protocol  used  in  long-haul  packet  switching  network  and  now  DoD 
standards.  MITRENET  was  the  first  LAN  that  exploited  the  CATV  technology  on  a 
dual-cable  broadband  system.  It  was  the  first  LAN  that  employed  a  16-bit  Z8000 
microprocessor  commonly  used  by  other  major  LAN  vendors  such  as  Sytek  and 
Ungermann-Bass .  MITRENET  was  also  the  LAN  that  supported  a  DMA  interface  to 
the  host  with  multiplexing  capability.  Based  on  these  facts,  MITRENET  was  and 
is  still  an  attractive  choice  for  a  testbed  LAN  system.  However,  MITRENET  was 
not  intended  to  be  and  will  probable  never  become  a  off-the-shelf  commercial 
product.  Therefore,  this  pilot  network  is  unsuitable  to  become  a  center-wide 
production  LAN  merely  because  of  the  tremedous  software  and  hardware 
maintenance  support  required  that  MITRE  Corp.  as  a  non-profit  organization  is 
not  chartered  to  commit. 

Under  the  assumption  that  the  MITRENET  is  to  be  replaced  by  a  full  scale 
DTNET  that  has  been  in  the  procurment  cycle  and  will  be  in  place  within  one 
and  a  half  year,  the  DTNSRDC  network  management  can  make  the  best  use  of  the 
MITRENET  to  provide  users  with  some  realistic  LAN  capability  so  as  to  contain 
their  over  expectation  in  order  to  better  prepare  for  the  smooth  introduction 
of  DTNET. 

During  this  interim  period,  the  MITRENET  can  be  kept  as  is  or  can  be 
enhanced  with  limited  capabilities  in  order  to  maximize  the  benefits 
realizable  before  the  DTNET  is  in  full  operation.  We  would  like  to  provide 
some  suggestions  for  the  enhancements  and  utilizations  to  MITRENET  is 
two-fold:  (1)  the  enhancements  and  utilizations  will  give  DTNSRDC  personnel 

a  more  reliable  network  and  (2)  by  implementing  these  enhancements  and 
utilizations,  DTNSRDC  personnel  will  gain  more  experience  in  network 
management . 

RECOMMENDATIONS  FCR  ENHANCEMENTS 

In  order  to  improve  network  performance,  the  following  enhancements  to 
t r.e  M ITRENET  are  desirable: 
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Hardware  Modification  to  the  DIU-UMCZgC  Interface  —  numerous 
problems  have  been  experienced  with  the  connectors  on  the  DIU-UMCZ80 
cable.  These  are  RS-232C  connectors.  These  connectors  can  easily 
come  loose  breaking  the  DIU-UMCZ80  link.  Replacement  of  the  RS-232C 
connector  on  the  RS-422  interface  with  a  different  type  of  connector 
that  can  provide  a  more  reliable  connections  between  the  DIU  and  the 
UMCZ80. 

(2)  Hardware  Modification  to  the  NIUs 

(a)  EPROM  Socket  Replacement:  Some  of  the  EPROM  sockets  on  the 
Z8000  developement  board  have  been  damaged  due  to  frequent 
insertions  and  removals  of  EPROMS  to  and  from  the  sockets. 
Replacing  the  EPROM  IC  sockets  on  the  NIL)  Zilog  development 
board  with  a  better  quality  socket  will  lengthen  the  life  of 
the  NIU  hardware  and  ease  future  enhancement. 

(b)  Addition  EPROM:  We  experienced  that  the  existing  EPROMs  were 
not  sufficient  in  system  modifications.  It  will  be  desirable 
to  have  addition  EPROMs  on  the  NIU  so  that  information  such  as 
user  table,  RCP  password,  etc.  can  be  stored  after  power  off 
and  be  changed  later  on  and  addition  system  parameters  can  be 
added . 

(3)  Set  up  Network  Control  Center  (NCC)  —  An  NCC  is  a  most  useful  tools 
to  debug  system  fault,  manage  network  operation,  and  maintain  system 
configuration.  We  recommend  setting  up  a  NCC  in  order  to  improve 
network  management.  The  following  suggestions  are  possible 
implementation  that  can  be  taken  to  set  up  a  NCC: 

(a)  RCP  Implementation:  Presently  only  HIU  (and  THIU)  software 
allow  RCP  to  perform  management  functions  on  the  interface 
ports,  changing  baud  rate,  tec.  It  will  be  essential  to 
implement  RCP  on  the  other  NIUs  (TIU  and  DIU)  so  that  all  NIUs 
can  be  controlled  through  RCP.  Special  privilege  will  be 
required  to  access  the  RCP.  The  implementation  of  RCP  should 
be  able  to  control  eacn  NIU's  baud,  reset  a  dummy  port,  etc. 
t  >  NCC  NIU:  One  of  the  'ossibie  ways  to  establish  an  NCC  is  to 
nave  a  special  NIU  programmed  as  a  NCC.  Periodic 
communications  between  the  NCC  and  every  NIU  to  gather  status 


and  statistical  information  an  each  NI'J  is  needed.  A  port  of 
the  NCC  NI'J  can  be  connected  to  a  microcomputer  or  minicomputer 
to  record  and  process  the  information  gathered  from  the  network 
for  future  analysis  and  network  management. 

4)  Software  Modification  to  NIU  Connections  --  In  order  to  imprive  the 
management  of  software  in  na.ndling  connections  between  NIUs,  we 
recommend  modifying  the  appropriate  algorithms  and  software  so  that 
for  each  virtual  connection,  a  timeout  mechanism  can  be  imposed  to 
ensure  the  active  utilization  of  the  virtual  circuit.  This  is 
particularly  important  to  those  users  who  logout  from  the  host 
without  disconnecting  the  virtual  circuit. 

5)  Software/Hardware  Modification  to  HIU-TIU  Connections  --  Modification 
of  the  HIU  software  and/or  hardware  so  when  a  session  between  a  TIU 
and  HIU  is  finished,  the  HIU  or  the  host  computer  is  able  to 
disconnect  the  virtual  circuit.  At  present,  the  connection  cannot  be 
closed  and  the  circuit  cannot  be  freed  without  the  initiation  of  a 
close  command  at  the  TIU.  The  ability  for  HIU  to  receive  initiative 
from  the  host  to  close  a  virtual  circuit  will  be  a  definite  plus. 

5}  Modification  of  NIU  Ports  --  The  HIU  presently  is  used  to  connect 

host  ports  and  the  TIU  to  connect  terminals.  IMS  suggests  combining 
these  two  kinds  of  NIU  into  one  so  that  these  NIU  ports  can  be 
conf igured/reconf igured  as  either  host  or  terminal  port3.  This  will 
simplify  management  since  in  this  arrangement,  only  one  kind  of 
EPROM  or  software  will  be  needed. 

7 )  Modification  of  NIU  Kardware/3of tware  to  Vary  Baud  Rate  --  It  will 
be  good  for  network  management  if  the  hardware  and  software  of  the 
NIU  are  modified  so  that  the  baud  rate  of  each  port  can  be  set 
individually.  This  will  allow  a  variety  of  devices  with  different 
baud  rates  to  be  served  by  a  single  MITRENET  interface  unit. 

t  ■  Modification  of  HIU  Software  to  Provide  Multiple  Port  Cluster  --  We 
suggest  to  modify  the  software  of  the  HI'J  so  that  each  cluster  of 
ports  can  service  one  multiple  host.  Accordingly,  the  user  can 
specify  different  host3  connected  to  the  same  HI'J.  This  can 
maximize  the  itilization  of  all  the  HIU  employ  the  same  logical 
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name.  If  more  than  one  host  are  connected  to  theHIU,  network  user 
can  easily  be  confused  by  the  chances  of  getting  onto  the  desired 
host . 

(9)  Modification  of  NIU  Software  to  Send  8-Bit  Characters  --  We  suggest 
to  modify  the  software  of  the  NIU  so  that  it  will  be  able  to  send 
8-bit  characters.  This  will  increase  the  NIU's  capability  to 
interface  with  more  devices. 

(10)  Modifications  to  TIU  Software  to  Allow  Transparent  Mode  -- 

Modification  of  the  software  of  the  TIU  to  have  a  transparent  mode 
after  a  connection  is  made  is  useful  for  certain  communication 
application.  This  will  provide  a  raw  mode  with  no  processing  of 
input  characters,  thereby  preventing  certain  characters  from  being 
captured  and  lost  by  the  MITRENET.  However,  further  enhancement  is 
needed  to  connect  the  circuit  when  the  session  is  finished. 

POSSIBILITIES  OF  MITRENET  UTILIZATION  AT  DTNSRDC 

In  order  to  improve  system  management,  we  suggest  the  following 
utilizations  of  the  MITRENET: 

(1)  Utilization  1:  The  HIU  can  be  used  to  connect  any  host  computer 
with  a  RS-232C  port  without  no  regard  on  whether  it  is  a  UNIX-based 
system  or  not;  therefore,  various  microcomputers  and/or 
minicomputers  can  be  accessed  through  MITRENET  via  the  HIU 
especially  if  enhancement  (8)  can  be  done.  This  will  increase  the 
utilization  of  thye  MITRENET. 

(2)  Utilization  2:  A  TIU  can  be  connected  to  host  computer  RS-232C 
ports  so  that  users  of  a  host  compute  are  able  to  access  MITRENET 
nodes  and  use  some  protocols  such  as  "kermit"  to  do  the  file 
transfers  between  hosts.  "Kermit"  is  an  interactive/ f ile  transfer 
protocol  which  is  available  in  the  domain  and  exists  on  hundreds  of 
UNIX  and  non-UNIX  machines.  We  have  transfered  files  of  3  MBytes 
from  one  VAX  to  another  via  TIU-HIU  connection  using  "kermit".  By 
connecting  the  TIU  to  the  host  computer  RS-232C  ports,  the 
capabilities  of  the  MITRENET  will  be  extended. 
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